An ITMS-91061: Missing privacy manifest rejection email looks as follows: ITMS-91061: Missing privacy manifest- Your app includes "<path/to/SDK>", which includes , an SDK that was identified in the documentation as a privacy-impacting third-party SDK. Starting February 12, 2025, if a new app includes a privacy-impacting SDK, or an app update adds a new privacy-impacting SDK, the SDK must include a privacy manifest file. Please contact the provider of the SDK that includes this file to get an updated SDK version with a privacy manifest. For more details about this policy, including a list of SDKs that are required to include signatures and manifests, visit: https://developer.apple.com/support/third-party-SDK-requirements. Glossary ITMS-91061: Missing privacy manifest: An email that includes the name and path of privacy-impacting SDK(s) with no privacy manifest files in your app bundle. For more information, see https://developer.apple.com/support/third-party-SDK-requirements. : The specified privacy-impacting SDK that doesn't include a privacy manifest file. If you are the developer of the rejected app, gather the name of the SDK from the email you received from Apple, then contact the SDK's provider for an updated version that includes a valid privacy manifest. After receiving an updated version of the SDK, verify the SDK includes a valid privacy manifest file at the expected location. For more information, see Adding a privacy manifest to your app or third-party SDK. If your app includes a privacy manifest file, make sure the file only describes the privacy practices of your app. Do not add the privacy practices of the SDK to your app's privacy manifest. If the email lists multiple SDKs, repeat the above process for all of them. If you are the developer of an SDK listed in the email, publish an updated version of your SDK that includes a privacy manifest file with valid keys and values. Every privacy-impacting SDK must contain a privacy manifest file that only describes its privacy practices. To learn how to add a valid privacy manifest to your SDK, see the Additional resources section below. Additional resources Privacy manifest files Describing data use in privacy manifests Describing use of required reason API Adding a privacy manifest to your app or third-party SDK TN3182: Adding privacy tracking keys to your privacy manifest TN3183: Adding required reason API entries to your privacy manifest TN3184: Adding data collection details to your privacy manifest TN3181: Debugging an invalid privacy manifest

In this post, we'll share tips to help you submit apps that deliver original ideas to your users. When working on your app, focus on creating interesting, unique experiences that aren't already available. Apps that actively try to copy other apps won't pass review, and accounts that repeatedly submit copycat apps or attempt to impersonate a service will be closed. The rules that prevent copycat and impersonator apps from being distributed on the App Store are described in App Review Guideline 4.1: 4.1 Copycats (a) Come up with your own ideas. We know you have them, so make yours come to life. Don’t simply copy the latest popular app on the App Store, or make some minor changes to another app’s name or UI and pass it off as your own. In addition to risking an intellectual property infringement claim, it makes the App Store harder to navigate and just isn’t fair to your fellow developers. (b) Submitting apps which impersonate other apps or services is considered a violation of the Developer Code of Conduct and may result in removal from the Apple Developer Program.(c) You cannot use another developer’s icon, brand, or product name in your app’s icon or name, without approval from the developer. These requirements help make the App Store both a safe place for people to discover apps and a platform for all developers to be successful. Best Practices Here are three best practices that will help you submit apps that follow App Review Guideline 4.1: 1. Submit apps with unique content and features. People want apps that provide unique experiences. Find areas that aren't currently being served and build compelling apps for those audiences. Do: Create apps that provide a new experience or a unique spin on an existing concept. Design original, delightful interfaces that elegantly meet your user's needs. Don't: Don’t imitate the features and functionality of other apps. Don’t copy the look and feel of other apps, such as using an identical user interface design. 2. Make sure App Store metadata only contains relevant information and content you either own or have permission to use. The metadata provided in App Store Connect is used to populate your app's product page on the App Store. People rely on this metadata to learn about your app and what it has to offer. Leveraging the popularity of another brand or app, either by including irrelevant references or protected content, is misleading and won't help your app succeed. Do: Use engaging, descriptive language to describe your unique app. Create original content that best represents your app, such as screenshots showing the actual app in use. Don't: Don't use protected material you do not have the necessary permission to use, such as app icons that are similar to icons of a popular app. Don’t include irrelevant references, such as popular app names or trademarked terms, in any metadata fields. 3. Provide information that is authentic and verifiable. People want to know the developers behind their favorite apps are who they say they are. It's important to continually review and provide up-to-date information, including the developer or company name listed on your Apple Developer Program account, the Support URL listed on your app's product page, and other helpful information. This will enable your users to contact you when they need help and it will also hinder people who may try to impersonate you, your app, or your service. Do: Make sure all information, resources, and documentation related to your account and apps are current and accurate. Don't: Don’t provide inaccurate information or resources, such as directing people to outdated support pages. Don’t provide fraudulent documentation. Accounts that submit fraudulent documentation will be removed from the Apple Developer Program. Support Incorporating these best practices into your app's development will help you submit apps that follow App Review Guideline 4.1. If you need additional assistance, consider taking advantage of one of the following support options available from App Review: If your submission has been rejected, reply to the message from App Review in App Store Connect and request clarification. Request an App Review Appointment to discuss the results of our review. Appointments are subject to availability, and take place during local business hours in your region on Tuesdays and Thursdays. If you believe your app follows the App Review Guidelines, consider submitting an appeal to the App Review Board. Resources Learn about foundational design principles from Apple designers and the developer community. Learn how to create engaging App Store product pages. Note that apps that violate intellectual property rights are subject to removal through the App Store Content Dispute process. If you believe an app on the App Store violates your intellectual property rights, you can submit a claim.

I have two questions regarding releasing an app that uses an in-app browser (WKWebView) on the App Store worldwide. Question 1: Encryption usage Our app uses WKWebView and relies on standard encryption. Should this be declared as using encryption during the App Store submission? Question 2: If the answer to Question 1 is YES If it must be declared as using encryption, do we need to prepare and upload additional documentation when submitting the app in France? Also, would this require us to redo the entire build and upload process, even for an app version that has already been uploaded? Goal / request: We want to release an app using WKWebView worldwide, including France. We would like to understand all the necessary steps and requirements for completing the App Store release without unexpected rework. Best regards, P.S.: A similar question was posted a few years ago, but it seems there was no response. https://developer.apple.com/forums/thread/725047 Sadao

Hello, I first submitted my app on September 14, and it has been stuck in the “Waiting for Review” status for almost three months now. This is the first version of the app, and it has never been reviewed before. I’ve already contacted Apple via email, but I only received the standard response stating that everything is fine. Is there anything else I can do? Thanks!

Hello, I’m writing to seek help regarding a serious App Review issue that has been ongoing for over three months. Our app has been under review since July 29, and despite providing all required explanations, documentation, and updates, we have not received any meaningful feedback for over a month — only repeated messages stating that “additional review time is required.” Timeline Jul 29–Aug 1: Apple rejected the app for not meeting the External Purchase requirements (Modal Sheet, canMakePayments). Jul 30–Aug 1: We explained that these requirements apply only to digital content, while our app also includes offline offerings permitted for external payment. Aug 3: Apple requested additional review time → Aug 12: requested demo account → Aug 21: we submitted a detailed explanation video and PDF. Early September: Apple sent detailed follow-up questions about whether each product type was considered digital. Mid-Sep to mid-Oct: Apple repeatedly replied with “additional review time required” without further updates. To fully comply with Apple’s payment policies, we even modified all product flows in our app to meet StoreKit requirements — even for offline products — and resubmitted the new version accordingly. However, the latest submission has now been “In Review” for over a week with no reviewer contact or feedback, even after we requested an expedited review. Meanwhile, our users have been stuck on the old version of the app for over three months, experiencing major issues and dissatisfaction. This delay is now critically affecting our service and business operations. Has anyone experienced a similar situation — where an app review has been stalled for months, even after providing all requested materials and being granted expedited review? If there are any possible ways to escalate or resolve this, I would be very grateful for your guidance. Thank you for any insights or advice.

I recently had my Apple Developer Account removed from the App Store. I have spent 3 months trying to reach someone at Apple who can clarify the issue and help reinstate our developer status. No one has responded to us, explained the situation, or reviewed the case. I was able to get in contact with an old Apple App Store executive. After hearing the story, he agreed the situation seemed wrong. However, he no longer has connections at Apple, so he wasn’t able to help us. The app had millions of users and 50,000+ five-star reviews. Resolving this would allow us to restore the app and continue launching new products. Right now I’d appreciate anyone’s thoughts or guidance on this situation. Thanks!

Start by refining your metadata with keyword-rich titles, subtitles, and descriptions that match user intent. Use high-quality screenshots, app previews, and localized content to improve visibility. Focus on user engagement through regular updates, positive reviews, and consistent installs. Higher retention and active user signals naturally help your app climb the App Store rankings.

"ASO in 2025 is more algorithm-driven, with a stronger focus on user engagement signals like retention and in-app actions. Keyword relevance still matters, but quality and user experience now play a bigger role in ranking boosts."

Hi all My radio streaming app (using Radio Browser API - open source, ODbL licensed) was approved for iOS but is being repeatedly rejected for macOS under Guideline 5.2.3 despite identical functionality. iOS version (approved): https://apps.apple.com/ch/app/pladio/id6747711658?l=en-GB Pladio Uses: radio-browser.info (community-maintained, ODbL license) Apple requests "documentary evidence" but hasn't clarified what form this should take for publicly broadcast radio streams. Other similar apps (TuneIn, Triode) are approved on both platforms. Has anyone successfully navigated a similar situation? What documentary evidence did you provide for publicly accessible content? Best regards, Patrick.

Hello everyone, I am writing to seek help with a critical App Review issue for a new application. My app has been in the "In Review" status for 29 consecutive days (since October 1st) without any change or feedback. This is on an experienced developer account with 5 other apps already live on the App Store. Here is the timeline of the current submission: Sep 30: Submitted new binary. Oct 1: Status changed to "In Review". Oct 9: After inquiring about the long delay, Developer Support kindly granted an expedited review (Case ID 102702095699). Oct 30 (Today): The app is still "In Review". It has now been 21 days since the expedited review was applied, and 29 days total. The core problem: My primary concern is that based on our server metrics, there has not been a single login attempt or health check from the App Review team since October 1st. This strongly suggests the app is technically "stuck" in the queue and has not even been opened or tested by a reviewer. We have been in constant contact with Developer Support, who have been very responsive and confirmed they escalated this internally with urgency. Unfortunately, despite these efforts, the app's status remains unchanged. This delay is now critical. We had firm, paid promotional integrations scheduled with partners for the first week of November, which were all dependent on an approval by our deadline of October 29th. We have now missed this deadline entirely, which is resulting in direct financial losses and reputational damage with our partners. Has anyone else experienced an app being "stuck" like this, where even an expedited review fails to get the app looked at? Is there any known technical glitch or a different path to get this specific blockage resolved? Thank you for any insights.

Hello everyone, I’m reaching out to seek guidance regarding an unusual delay in the App Review process. Two of our new apps have been in the “Waiting for Review” status since October 30, 2025, with no change or update from the review team. Both submissions were uploaded from an active, established developer account that already has multiple live apps on the App Store. We reached out to Apple Developer Support, and they kindly confirmed that the issue has been escalated under Case ID: 102741157121. However, as of today, both apps continue to remain in the same status without any progress. At this point, we’re concerned that the apps might be stuck in the queue due to some technical issue, since no review activity seems to have started yet. Has anyone else experienced a similar delay recently, or found any effective way to get such stuck submissions moving again? Any insights or advice would be greatly appreciated. Thank you in advance.

Our app was rejected on October 23. After communicating with the App Review team on October 24, the decision was still the same, so we submitted an appeal to the App Review Board that day. It's over 17 days later, and we still haven’t received any update. We totally understand that the review process can take some time, but this new version includes a major self-developed feature that took us quite a while to build, and we’re really hoping to get it online for validation soon. Does anyone know how long it usually takes to get a response from the App Review Board? Or is it okay to follow up with them again at this point? Thank you for any insights.

I already created subscription in appstore connect with proper metadata still when I am using product id to purchase the subscription using flutter package in_app_purchase: ^3.2.3 it say's no subscription found with product id x. I observed everything minutely all seems fine than why ?? I try to test with storekit that works btw. I also have sandbox account and same signed in my iPhone 12 mini but much please look into this.. Flutter code : Future<void> _loadSubscriptions() async { Set<String> kSubscriptionIds = {'monthly_plan_test_iop_81'}; ProductDetailsResponse response = await _inAppPurchase.queryProductDetails(kSubscriptionIds); if (response.notFoundIDs.isNotEmpty) { kLog("Subscription IDs not found: ${response.notFoundIDs}"); } kLog("God it works seriously"); kLog(response.notFoundIDs); kLog(response.productDetails); kLog(response.error); subscriptions.value = response.productDetails; }

Hi, I want to consult about this: This is regarding [Guideline 5.1.1 - Legal - Privacy - Data Collection and Storage] My client is asking if we can remove the new account registration through the iOS App, so we won't need to ask for mobile and birthdate. For iOS App users, new users will register through the website (or through a non-Apple related app). After registering through the website, they can access the iOS App using the credentials created through another method. Will that be a problem with Apple policies? My client said they need the Mobile number and birthdate for verification. Thanks in advance for the help and guidance. Best regards, Sophia

I hope you are doing well. I am reaching out to follow up regarding my app, which has been under App Review for an unusually long period of time. I have contacted Apple Developer Support several times through both phone calls and emails, but so far, there has been no effective resolution or progress. Below are the case references from the last few weeks: • Case ID: 102741157121 — App Store Connect Users and Roles • Case ID: 102745063464 — Program Enrolment • Case ID: 102744897406 — Other Membership or Account Questions • Case ID: 102742872512 — App Review Status • Case ID: 102742874797 — App Review Status • Case ID: 102743079324 — Developer Team Management • Case ID: 102738804525 — Feedback and Other Topics • Case ID: 102735998715 — Agreements and Contracts • Case ID: 102735996938 — App Review Status • Case ID: 102725767721 — Other App Review Questions • Case ID: 102725766192 — App Review Status • Case ID: 102729318336 — My Issue Is Not Listed • Case ID: 102723997813 — Program Enrolment As you can see, I have made numerous attempts to resolve this matter, yet I have not received any concrete response or outcome. My app continues to remain in the “In Review” state without any progress or communication from your team. This repeated delay is affecting my project timeline and business operations. I respectfully request that this issue be escalated to a senior App Review specialist or higher-level reviewer who can take direct action. Please review the above case history and provide a clear resolution or update at the earliest possible. Thank you for your attention and understanding.

Our iOS/iPad app is built with React Native. We use Axios as our HTTP client. Our app has been out on the app store for 2+ years and we've never had issues with reviews. Since iOS 26 came out, our app has been constantly getting rejected because the Apple tester keeps facing network timeout issues when our app makes requests to our API services. Our API stack is already configured to support IPv6 networks, and our regular user base does not run into the issues the Apple tester is seeing. None of our developers nor our internal testers have been able to reproduce the issue the Apple tester is facing. We've tried a number of things to debug the potential issue: Added a ping check on app startup. We used the native fetch present in React Native apps as well as our Axios client (with the default XHR/HTTP adapter). None of the pings make it to our API services. Added higher timeouts on app startup to let the Apple tester have more time to reach our services while their simulator device is able to connect. We've read that the environment that Apple testers use can sometimes take longer to establish an initial connection, even though packages like NetInfo from React Native report that they are connected to WiFi as soon as the app starts. Switched our Axios client adapter to use the native fetch. We did this since we noticed that Mixpanel, our tracking library, uses the native fetch in their React Native SDK and we've confirmed that requests on their end do make it through when the Apple tester is testing our app. We're running out of ideas since the issue is pretty obscure and we haven't been able to reproduce it yet, not even by following the Apple guide to set up a local IPv6 NAT64 network to be as close to their environment as possible. We've also tried testing the app while connected to VPNs from different locations to no avail. Like I said before, we noticed that this issues started for the Apple tester with the release of iOS 26, so we're wondering if there are known issues in the community that might relate to what we're experiencing. The most recent finding we've made is that some other developers report new issues with HTTP 3/QUIC on iOS. We've seen recommendations about turning off explicit support for HTTP 3 on our services, which seems to have helped other developers.

Dear App Review & App Store policy team, I am writing as an independent macOS developer who has spent more than the last six months building TilesWM, a full‑featured window‑manager that rivals existing products such as Magnet, Divvy and BetterSnapTool. The app works exactly like those solutions: it uses the Accessibility (AX) API to move and resize arbitrary windows, registers global hot‑keys, and stores user preferences locally in ~/Library/Application Support/<bundle‑identifier>. When I attempt to submit TilesWM through App Store Connect the validation process failed with two errors, one of which was relatively easily solvable with the help of "ssmith_c" and "Quinn". The other, the hard blocker: Sandbox not enabled – the app does not contain the required com.apple.security.app-sandbox = true entitlement. but: The same accessibility entitlement is absent from the binaries of Magnet, Divvy, BetterSnapTool and other window‑manager apps that are already available on the Mac App Store. Those applications were on the Store before Apple introduced the mandatory sandbox requirement (≈ macOS 10.7.3-ish). Consequently, they continue to operate without a sandbox while new entrants are forced either to abandon the platform or to distribute outside the App Store. This situation creates an uneven playing field that contradicts Apple’s stated commitment to an open and competitive ecosystem. All developers pay the same $99 annual fee and should follow identical review guidelines; yet legacy window‑manager apps enjoy a privileged exemption that new developers cannot obtain, effectively granting them a perpetual non‑compete advantage. What I am asking for Clarification: Is a missing Sandbox entitlement truly unsupported for Mac App Store distribution or is there a way to "request" an exception? Policy action: Please evaluate an option to provide a concrete path forward so that TilesWM can be submitted without having to abandon the App Store. Point of contact – If this issue falls outside the scope of App Review, kindly direct me to the team or individual responsible for macOS sandbox policy decisions. I remain committed to distributing my app through the Mac App Store because it is the primary channel users trust and expect. I believe that a fair resolution will benefit developers, Apple, and end‑users alike by expanding the selection of high‑quality window‑management tools. Thank you for your attention to this matter. I look forward to a constructive response and to working together toward an equitable solution. Respectfully, Denis Steinhorst Full‑Stack Engineer & macOS enthusiast Bundle ID: dev.steinhorst.tileswm

My game has been live since 2018 and I’ve been updating it recently to add some improvements because it’s been a few years (last update was 2020). I got hit with a couple of basic issues with the screenshots but I was told I can release that version anyway and fix it in a later update. I spent yesterday fixing those issues because they were minor, and resubmitted my app to review. This morning I was hit with another rejection for a new issue, 4.3(b) Design Spam. The reason being it’s a game in a saturated category (Beer Pong) and so I should reconsider the app concept. This game has been live for 7 years. In those 7 years the category may have become saturated, but it wasn’t when I originally released it, so stopping me from updating it feels extremely unfair. If this was a brand new app I would still be upset but I would understand. Another reason was that it’s based on a drinking game, and that it encourages people to drink alcohol. I stated in the age rating section that it heavily contains alcohol references, although you never actually see anyone drinking. There are Beer Pong games that feature characters drinking the beer, mine is so inextreme in comparison. What bugs me the most is if I hadn’t fixed the screenshots it would be live by now, yet I feel I’m being punished for following the rules. Can anyone on here give me some advice on how to proceed? I have to say this entire dilemma has really taken the wind out of my sails. If this update doesn't get accepted I'll have wasted about two months of development time I could've spent on a different project.

Hello App Review Team, The last the three review submissions including the current one have been stuck on "Waiting in Review" for more than 7 days for the first two times and currently 4 days now for the current submission. I was wondering if something happened that is causing this issue. Thanks and Regards

I recently released the first version of my app, and it was discoverable via App Store search. After pushing an update with bug fixes and improved keywords/category, the new version went live and showed as “Ready for Sale” within hours. However, since the update, the app no longer appears in App Store search results - even when searched using its exact name. It’s still accessible through the direct link. Any insights or guidance would be greatly appreciated!

My submission was rejected twice for "framing in the preview video". I couldn't understand why because there was no framing. Then on the 2nd rejection I noticed an included screenshot. The screen shot wasn't from my new preview video but from the old (they are very old) preview videos that are currently approved and live on the app store. Why did this happen? Because I had uploaded my new videos to the app update and decided before submitting I would run an A/B test to make sure they performed as well or hopefully better. When I went to the "Product Page Optimization" section I found my new videos already there. However... The new preview videos were in the "Original Product Page" and the old videos were in "Treatment A". I asked ChatGPT about this and it said not to worry it was a known quirk. What has obviously happened is that when the reviewer reviewed my Product Page Opt test they were presented with the old videos from Treatment A and not the new videos which were in "Original Product Page", as proven by the screenshot from the old, approved, live, video. I've submitted my app update but you seem to be just sitting on it now. I'm guessing because I'm black marked as not fixing an issue and constantly resubmitting unfixed. Please don't punish me for your mistakes....